Integration Tests

At this point, we can create real tests in the test_postgresrepo.py file and replace our test_dummy function. All tests receive the app_configuration, pg_session, and pg_test_data fixtures. The first fixture allows us to initialize the PostgresRepo class with the proper parameters. The second fixture creates the database with our test data. Finally, the third fixture contains the database.

Impact on our test cases#

The tests for this repository are a copy of the ones we created for our MemRepo repository. This is not surprising. Usually, we want to test the very same conditions, regardless of the storage system we are currently using. However, toward the end of this chapter, we’ll see that, while these files are initially the same, they can evolve differently. This can be due to the occurrence of bugs or corner cases resulting from specific implementations, such as in-memory storage, PostgreSQL, etc.

It’s important to remember that we introduced these tests one at a time and the full TDD workflow is not shown here for the sake of brevity.

Impact on the entity#

We developed the code of the PostgresRepo class following a strict TDD approach, and we recommend that everyone applies this same method. We’ll now place the resulting code in the rentomatic/repository/postgresrepo.py directory, the same one where we created the postgres_objects.py file.

We can see that PostgresRepo is very similar to our MemRepo repository. This is because our particular case—namely the list of Room objects—is pretty simple, so we don’t expect to see a lot of differences between an in-memory database and a production-ready relational database. However, as the use cases become more complex, we’ll need to leverage the features provided by the engine we’ve decided to use, while methods such as list may evolve and become very different.

It’s important to note that the list method returns domain models. This is allowed because the repository is implemented in one of the outer layers of the architecture.

When we set up a proper integration testing environment that isn’t trivial, the changes our architecture requires to work with a real repository are limited. We think this is a good demonstration of the flexibility of a layered approach, such as the one at the core of clean architecture.

Updated code#

We’ve updated our files with the new code in the code editor.